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Title of the invention 

Method, system, and network entities for processing 
service requests in a domain of a domain-based network 

5 

Field of the invention 

The present invention relates to a method, a system, and 
network entities for processing service requests in a 
10 domain of a domain-based network. In particular, such a 
domain-based network consists of a plurality of domains 
and may be exemplified by the Internet or a Third 
Generation (3G) mobile communication network. 

15 Background of the invention 

In recent years, communication technology has widely 
spread in terms of number of users and amount of use of 
the telecommunication services by the users. This also 

20 led to an increase in the number of different 

technologies and technological concepts nowadays in use. 
Additionally, the demands of users as well as the kind 
and number of services has significantly increased. There 
also exists a trend of merging different kinds of 

25 networks providing different services into each other in 
order to offer high comfort to the user and to integrate 
these services into each other. For example, charging a 
user for communication or used information services can 
be performed by a specialized service/network which is 

30 distinct from those services/network systems which are in 
charge of enabling the communication as such via the 
information network . 

Many existing and future networks like the Internet are 
35 organized in a domain-based manner. This means that the 
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whole network is constituted of a plurality of individual 
administrative areas, which are known as domains or 
realms. Each such domain covers a relatively small 
region, but by an inter-connection of many of such 
5 domains, the whole network can achieve an enormous 

coverage in terms of area and users. Additionally, each 
such domain itself can again be organized in a domain- 
based manner being constituted of so-called sub-domains. 
Such a network configuration represents a hierarchical 
10 structure and is advantageous for administration and 
operation of a large amount of users. 

The individual domains are built up, organized and 
managed by a respective service provider, and they are 
15 organizationally confined and independent but inter-v, 
connected with each other. ; 

A popular example for such a domain-based network is the 
Internet with the Internet service providers (ISP) 

20 providing individual inter-connected networks 

representing the domains. In this context, the term of a 
user's or user terminal's *home domain' means the 
particular domain of the ISP with which a user or user 
terminal is registered. The well-known address format for 

25 Internet communications therefore is usernameQhomedomain . 

In a domain-based network arrangement as described above, 
each service provider basically provides for 
communication or information services for the users 

30 registered with him. Today, however, there exist many 
security relevant and/or user-related services which 
makes the provision of security aspects such as 
• authentication and authorization mandatory in 
communication networks. Many future Internet services or 

35 mobile communication services will also require such 
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functions. The rules and directives to be followed by 
users having access to databases, systems and resources 
can be summarized by. the term ^security policy". If a 
user, for example, wants to use a security-relevant 
5 service of another service provider, the user has to 

authenticate and/or authorize himself. For this purpose, 
he needs a password, a security key or the like. Such 
information can be managed in a centralized way or by a 
specialized network or part of a network providing such 
10 user-related services. 

Additionally, the aforementioned inter-connection of 
domains enables a user to utilize services of service 
providers different from his own service provider and 
15 also within domains different from his home domain. This 
feature is often referred to as roaming and makes an 
additional accounting functionality necessary, for 
example, in order to gather billing, auditing and 
reporting information about the „visiting" user. 

20 

Conventionally, a specialized network for performing such 
functions as described above is built up „on top of" the 
communication network, and is often referred to as AAA 
(authorization, authentication and accounting) network. 

25 The thus realized functions like system access and 

database look-ups can take place in specific and separate 
AAA nodes, but in practice, these nodes are often 
implemented within the nodes of the underlying 
communication network, which has the advantage of a joint 

30 use of hardware and thus reduced costs. Notwithstanding 
the hardware location, the AAA nodes offer a 
functionality which is distinct from other 
functionalities. Therefore, in the following 
specification a node is individually addressed as long as 
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it provides a distinct functionality irrespective of its 
physical location or implementation. 

For the sake of clarity and simplicity, it will 
5 hereinafter only be referred to AAA nodes. The structure 
of the AAA network is also in line with the underlying 
communication network like the Internet or a 3GPP 
network. More specifically, an AAA network servicing a 
domain-based communication network is also organized in a 
10 domain-based manner. 

The use of AAA techniques provides as benefits an 
increased flexibility and control, scalability, and the 
usage of standardized authentication methods. However, 

15 specialized security and routing protocols are also 

needed for performing AAA functions properly and f or i ?, 
routing respective messages related to AAA functions. 
Examples for such standardized AAA protocols , which are 
known to a skilled person, include RADIUS (Remote Access 

20 Dial-In User Services) which is standardized by the IETF 
(Internet Engineering Task Force), TACACS+ (Terminal : 
Access Controller Access System) implemented by Cisco®, 
and Kerberos. These protocols are used for dial-in and 
terminal server access to the AAA network mainly from 

2 5 outside the domain. As an example, a user roaming in a 

domain of another service provider than his own provider 
has to authenticate himself within this domain. 
Therefore, he sends a request to an AAA node within his 
home domain for providing him with the required services 

30 like a password. Recently, the AAA Working Group of the 
Internet Engineering Task Force (IETF) is under way of 
standardizing a new RADIUS-based AAA protocol called 
Diameter . 
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The subsequent description focuses on the use of the 
Diameter protocol for these purposes of AAA. However, 
this serves as an example only and the principles 
underlying the present invention are also applicable to 
5 domain-based networks operating under another protocol as 
long as this other protocol is similar to the Diameter 
protocol and supports or is compatible to at least the 
routing functionality offered by Diameter. 

10 The Diameter base protocol provides a session-oriented 
and policy-based framework for the functionality of 
Diameter routing of messages called (AAA) service 
requests. It is based on the nowadays commonly used 
challenge-response-type RADIUS protocol which is located 

15 at the network layer of the OSI network model. Diameter 
dial-up services are, for example, further on based on 
PPP (Point-to-Point Protocol) connections, but roaming 
support is enhanced, and the Mobile IP model is 
integrated, making Diameter the AAA protocol for the 

20 future. The terminology defined by the IETF in the 

version of the Internet draft which was found on their 
website at http : //www. ietf . org /internet -draf ts /draft - 
ietf-aaa-diameter-17.txt on August 20, 2003 will form the 
basis for the terms used in the further specification. 

25 

Hitherto, when large amounts of users are administered by 
a service provider, i.e. within an individual domain, it 
is reasonable to deploy the AAA network in a hierarchical 
way. Fig. 1 shows such a hierarchical AAA deployment in a 
30 domain-based manner. In the following, the structure and 
operation of the system according to Fig. 1 will be 
described. In Fig. 1, the dashed lines represent 
bidirectional connections between entities being linked 
by these lines, and the dash-dotted lines indicate the 
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administrative areas, i.e. the boundaries of the domains, 
operated by a respective service provider. 

As can be seen in Fig. 1, a domain-based network 
5 generally comprises of a plurality of domains Dom_A, 

Dom_B, Dom_C, each of which is respectively administered 
by a separate service provider A, B, C. Although there 
are three such domains of three service providers shown 
in Fig. 1, such a network may comprise any number of 
10 domains. In between all domains, i.e. not belonging to an 
administrative sphere of one service provider, there can 
also exist network nodes. As an example, an AAA 
redirector R, the usage of which will be explained below, 
is depicted in Fig. 1. 

15 

Domains can be expected to have the same basic ; 
constitution. Hence, only domain A is described and a 
similar description of domains B, C is omitted. 

20 Further, the hierarchical structure of an AAA network -4/. 
within a domain of service provider A is shown in detail 
in Fig. 1. The highest hierarchy layer consists of an ■ ^ 
entry node Al of the domain Dom_A, e.g. an AAA proxy, 
which serves as an interface between this and other 

25 domains. This entry node is, therefore, connected to the 
AAA redirector R between all domains, to entry nodes Bl, 
CI of other domains, and to nodes of a lower hierarchy 
layer of Dom_A. In this second hierarchy layer, a 
plurality of service nodes A3a, A3b, A3c, e.g. AAA 

30 servers are located which provide the above-mentioned 
user-related services such as AAA services. As can be 
seen in Fig. 1, these service nodes are connected to each 
other. In a third hierarchy layer, a plurality of access 
nodes A3al, A3a2; A3bl, A3b2; A3cl, A3c2 is connected to 

35 each respective service node A3a; A3b; A3c. A user can 
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access the network via these access nodes (AR: access 
router) . 

It is to be noted that throughout the following 
5 description the term „user" shall always to be understood 
either as the user itself or as a user terminal by means 
of which the respective user connects to the network. 

Each user registered with service provider A, i.e. in 
10 this domain Dom_A, is fixedly associated with one of the 
plurality of service nodes A3a, A3b, A3c, e.g. AAA server 
Beijing. The respective service node (also known as 'home 
server' of this user) manages method lists containing 
user and service information needed for the operation of 
15 the AAA functions related to this user. For example, 

policy information for authorization like passwords and 
security keys of a user for a special service is stored 
in these methods lists. A user being associated with AAA 
server Beijing A3a, for example, is assumed to access the 
20 network via an access node connected to this service 
node, e.g. AR Beijingl A3al or AR Beijing2 A3a2 . 

The above structure also applies to AAA networks in other 
domains Dom__B, Dom_C, which is indicated by displaying 
25 the respective entry nodes (Bl, CI) . ' 

AAA-related service requests intended for other domains 
exit the domain through the entry node Al of the domain 
in which domain they are originated, and are transmitted 

30 to the AAA redirector R representing a domain-independent 
entity. In general, redirectors refer clients to servers 
and allow them to communicate directly. More 
specifically, redirectors obtain destination information 
for messages in order to enable a correct routing and 

35 forwarding of these messages. Since redirectors are j 

f 
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generally not located in the forwarding path, they do not 
alter any information fields in the service request being 
handled. Service requests that are handled by an entry 
node Bl of a domain B and aim to a domain A (which is 
5 unknown to domain B) are rather forwarded to the 
redirector R for obtaining information about the 
destination domain A. The redirector finds out the 
address of the entry node Al of the desired domain A. It 
then sends back the required information on how to reach 
10 the addressed domain A to the entry node Bl. Then, entry 
node Bl is enabled to forward the service request to 
entry node Al . 

AAA-related messages, i.e. AAA service requests, coming 
15 from outside the domain of service provider A are handled 
locally by the entry node Al . The incoming message 
usually contains the destination domain and the user name 
for whom AAA functions are requested. The handling of the 
service request thus comprises a look-up of the 
20 destination host ('home server') of this user, i.e. a 

service node A3a, A3b, A3c, in a user database, and a f, 
subsequent forwarding of the service request to the AAAi 
server with which the respective user is associated. 

25 Fig. 2 is an illustration showing the internal protocol 
structure of nodes of domain A according to Fig. 1. In 
detail, the entry node Al, two service nodes A3a, A3c and 
two access nodes A3a2, A3cl, one in connection with each 
service node, are shown as an example. It can be seen 

30 that the internal structure in terms of an implemented 
protocol stack, e.g. the protocol stack of the Diameter 
base protocol, of each of these nodes is comparable. In 
this regard, each of these nodes comprises a transport 
layer, a peer FSM layer, a session FSM layer, and an 

35 application layer of the respective security protocol (in 
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this case, Diameter) . Further, it can be seen that the 
physical connections between the nodes are established 
between the respective transport layers. Since a skilled 
person knows the functions of each layer, a detailed 
5 description thereof is omitted here. 

Fig. 3 shows a home server (destination) determination 
procedure in response to an AAA service request according 
to the prior art. The illustration differs from the 

10 illustration of Fig. 2 in that the processing of an 

incoming service request is shown by the numbered arrow 
lines. The exemplary procedure refers to a user being 
associated with a service node with the address 
aaa.beijlng.china.com, which user is roaming in another 

15 domain and has originated a service request from there. 

The incoming service request (solid arrow line from the 
right edge) is (1) input to and processed by the peer FSM 
(finite state machine) layer of the local AAA proxy, i.e. 

20 the entry node Al . The service request is further 

transfers to the application layer of the entry node Al . 
The application layer handles a look-up (2), which is 
indicated by a dashed arrow line, in a user database DB_A 
for obtaining the required destination information. The 

25 result of this look-up is included into the service 

request, again processed (3) in the application layer and 
transferred to the peer FSM layer. The thus adapted 
service request is then, based on the information 
retrieved from the database and included (3) in the 

30 service request, forwarded (4) to the destination service 
node (home server) of the user under discussion. At the 
server, in this example aaa.beijing.china.com, the 
service request is finally processed in the peer FSM 
layer of service node A3a and transferred to the 

35 application layer for providing the required service, 



4 t 



- 10 - 

e.g. XXX. The access node, in this example 

beijing2.beljlng.china.com A3a2, via which the user under 
discussion would access the network, if he was not 
located in a foreign domain, is not involved in this 
5 procedure. 

However, the AAA deployment described above has some 
problems and drawbacks in practice. 

10 First, the local handling of all incoming messages by the 
proxy, i.e. the performing of the database look-up and 
the processing through a multitude of protocol layers, is 
problematic. Every user being associated with a domain 
and currently roaming in a foreign domain has to send a 

15 service request back to his home domain, if he needs -an 
AAA service. Especially, when large amounts of users? are 
registered in service provider A' s domain, it is likely 
that many users of this service provider are roaming "in 
other domains at the same time (taking into consideration 

20 a high mobility of users) . The entry node of domain A: can 
then easily be loaded over burden due to many service 
requests being input in a short time interval. This can 
delay the required operation which is unacceptable under 
today's communication requirements. 

25 

Second, there occurs a problem, when several service 
nodes share the same domain name, e.g. china.com for 
service nodes aaa.beijing.china.com and 

aaa . hongkong. china . com, which is the case in the above- 
30 described example. Such a scenario is comparable to the 
above-mentioned sub-domains. In this case, users are not 
likely to specify their service nodes with which they are 
associated (home servers) when they roam under another 
service node within their home domain. Since the 
35 necessary redirect actions are, according to prior art, 
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based on the domain name and user name only, this would 
lead to a problem in the processing of such intra-domain 
service requests, 

5 Summary of the invention 

Consequently, it is an object of the present invention to 
remove the above drawbacks inherent to the prior art and 
to provide an improved system for processing service 

10 requests in a domain of a domain-based network. Also, it 
is an object of the present invention to provide a method 
for processing service requests in a domain of a domain- 
based network. Additionally, it is an object of the 
present invention to provide network devices capable of 

15 being used within the system of the present invention and 
of performing the method of the present invention. 

According to a first aspect of the present invention, the 
above objects are achieved by a method for processing 

20 service requests in a domain of a network which network 
consists of a plurality of domains, wherein said service 
requests originate from a user terminal associated with a 
service node of said domain, and wherein a domain at 
least comprises a service request input node, an 

25 intermediate node, a database, an entry node, and a 
plurality of service nodes, and wherein said service 
request input node is connected to said intermediate 
node, to said entry node and to said service nodes, said 
intermediate node is further connected to said database 

30 and to said service nodes, and said service nodes are 

further connected to each other; said method comprising 
the steps of: analyzing an incoming service request in 
said service request input node in terms of destination 
information contained in said service request; 

35 determining in said service request input node, whether 
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the destination information enables a direct forwarding 
of said service request to its destination; redirecting 
said service request by said service request input node, 
if said determining yields that said direct forwarding is 
5 not enabled; wherein said redirecting comprises the steps 
of: transmitting said received service request by said 
service request input node to said intermediate node; 
based on said received service request, performing a 
look-up in said database by said intermediate node for 

10 obtaining destination information required to enable a 
forwarding of said service request to its destination; 
sending said destination information from said 
intermediate node to said service request input node by; 
and based on said sent destination information, 

15 forwarding said service request from said service request 
input node to its destination. i 1 

.♦ 

V. 

4 

According to further advantageous aspects: 

,V 

20 - the method further comprises a step of direct f. 
forwarding said service request by said service request- 
input node to its destination, if said determining yields 
that said direct forwarding is enabled; 

- said service request input node is an entry node of 
25 said domain, and said entry node receives said service 

request from outside of said domain; 

- said service request input node is one of a plurality 
of service nodes of said domain, with which the user 
terminal originating said service request is not 

30 associated, wherein said one of the plurality of service 
nodes receives said service request from within said 
domain; 

- said service request input node determines that the 
received service request from within said domain is 

35 destined for a user terminal being associated with a 
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service node of said domain, and in response thereto 
redirects said service request; 

- said service request input node determines that the 
received service request from within said domain is 

5 destined for a user terminal not being associated with a 
service node of said domain, and forwards said service 
request to said entry node of said domain for relaying 
said service request to another domain; 

- said entry node of said domain is a proxy node; and 
10 - said entry node of said domain is a relay node. 

According to another aspect of the present invention, the 
above objects are achieved by a system for processing 
service requests in a domain of a network which network 

15 consists of a plurality of domains, wherein said service 
requests originate from a user terminal associated with a 
service node of said domain, and wherein a domain at 
least comprises a service request input node, an 
intermediate node, a database, an entry node, and a 

20 plurality of service nodes, and wherein said service 
request input node is connected to said intermediate 
node, to said entry node, and to said service nodes, said 
intermediate node is further connected to said database 
and to said service nodes, and said service nodes are 

25 further connected to each other; said system comprising: 
analyzing means in said service request input node which 
analyze an incoming service request in terms of 
destination information contained in said service 
request; determining means in said service request input 

30 node which determine, whether the destination information 
enables a direct forwarding of said service request to 
its destination; redirecting control means in said 
service request input node which control a redirecting of 
said service request, if said determining means yields 

35 that said direct forwarding is not enabled; wherein said 
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redirecting is performed by: transmitting means in said 
service request input node which transmit said received 
service request from said service request input node to 
said intermediate node; look-up means in said 
5 intermediate node which perform, based on said service 
request received by receiving means, a look-up in said 
database for obtaining destination information required 
to enable a forwarding of said service request to its 
destination; sending means in said intermediate node 
10 which send said destination information from said 

intermediate node to said service request input node; and 
forwarding means in said service request input node which 
forward said service request, based on said sent 
destination information, from said service request input 

15 node to its destination v; 

.}■ ■ 

According to further advantageous aspects: { 

- the system further comprises forwarding means in said, 
20 service request input node which forward said service 

request to its destination, if said determining means 
yields that said direct forwarding is enabled; * v ' 

- said service request input node is an entry node of 
said domain, and said entry node receives said service 

25 request from outside of said domain; 

- said service request input node is one of a plurality 
of service nodes of said domain, with which the user 
terminal originating said service request is not 
associated, wherein said one of the plurality of service 

30 nodes receives said service request from within said 
domain; 

- said service request input node comprises determining 
means which determine, whether the received service 
request from within said domain is destined for a user 

35 terminal being associated with a service node of said 
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domain, and redirecting means which redirect said service 
request, if said service request is destined for a user 
terminal being associated with a service node of said 
domain; 

5 - said service request input node comprises determining 
means which determine, whether the received service 
request from within said domain is destined for a user 
terminal not being associated with a service node of said 
domain, and forwarding means which forward said service 

10 request to said entry node of said domain for relaying 
said service request to another domain, if said service 
request is destined for a user terminal not being 
associated with a service node of said domain; 
- said entry node of said domain is a proxy node; and 

15 - said entry node of said domain is a proxy node. 

According to another aspect of the present invention, the 
above objects are achieved by an intermediate node which 
redirects service requests within a domain of a network 

20 which network consists of a plurality of domains, wherein 
said intermediate node is connected to an entry node, to 
a database, and to a plurality of service nodes of said 
domain; said intermediate node comprising: (a) receiving 
means which receive said service request from a service 

25 request input node; (b) look-up means which perform, 

based on said received service request, a look-up in said 
database for obtaining destination information required 
to enable a forwarding of said service request to its 
destination; (c) sending means which send said 

30 destination information from said intermediate node to 
said service request input node. 

According to another aspect of the present invention, the 
above objects are achieved by a service node of a domain 
35 of a network which network consists of a plurality of 
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domains, wherein said service node provides services for 
a user terminal associated with said service node, which 
services are requested by service requests originating 
from said user terminal, wherein said service node is 
5 connected to an entry node of said domain, to an 

intermediate node of said domain which redirects service 
requests within said domain, and to all other service 
nodes of said domain. 

10 According to another aspect of the present invention, the 
above objects are achieved by a service request input 
node within a domain of a network which network consists 
of a plurality of domains, wherein said service request 
input node processes service requests originated from 

15 user terminals of said network, and wherein said service 
request input node is connected to an intermediate node' 
of said domain which redirects service requests within : a 
domain, and to a plurality of service nodes of said %t 
domain; said service request input node comprising: 

20 redirecting control means which control a redirecting of 
a received incoming service request; transmitting means" 
which transmit said received service request to said 
intermediate node for obtaining destination information 
required to enable a forwarding of said service request 

25 to its destination; forwarding means which forward said 
service request, based on said received destination 
information, from said service request input node to its 
destination . 

30 According to further advantageous aspects: 

- said service request input node is an entry node of 
said domain, and receives said service requests from 
outside of said domain; 
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- said service request input node is a service node of 
said domain, and receives said service requests from 
within said domain; 

- the service request input node further comprises 

5 determining means which determine, whether the received 
service request from within said domain is destined for a 
user terminal being associated with a service node of 
said domain, and redirects said service request, if said 
service request is destined for a user terminal being 
10 associated with a service node of said domain; 

- the service request input node further comprises 
determining means which determine, whether the received 
service request from within said domain is destined for a 
user terminal not being associated with a service node of 

15 said domain, and forwarding means which forward said 
service request to an entry node of said domain for 
relaying said service request to another domain, if said 
service request is destined for a user terminal not being 
associated with a service node of said domain. 

20 

Furthermore, advantageous aspects of the present 
invention include that said service requests are AAA 
service requests associated with authentication, 
authorization, and accounting functions, and that service 
25 requests are processed based on the Diameter base 
protocol . 

Furthermore, advantageous aspects of the present 
invention include that the network consisting of a 
30 plurality of domains is the Internet and the domains are 
established by respective service providers, or that the 
network consisting of a plurality of domains is a 3G 
mobile communication network 
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An advantage of the present invention is the provision of 
a mechanism to process incoming messages to a correct 
service node within the hierarchy of nodes of a domain of 
a network which consists of a plurality of domains. This 
5 can be performed with least spending of an entry node and 
with no modifications to the utilized protocol. In 
particular, the requirements on an entry node are 
alleviated in that it is possible to replace a proxy 
implementation by a relay implementation. This saves cost 
10 and implementation effort and can improve the robustness 
of the system. 

It is a further advantage of the present invention that 
roaming within sub-domains, i.e. roaming under another 
15 service node within a home domain of a user, is easy to 
achieve. Even when new (e.g., Diameter) applications ,are 
adopted, no update to the entry node is needed. * ; 

jf 

Furthermore, it is an advantage of the present invention 
20 that the burden of an entry node when handling service \ 
requests can be reduced, a redirecting function within ia 
domain is implemented, and such a solution can be ^; 
deployed in the cascade way within a very large 
hierarchical framework . 

25 

Yet another advantage is that the use of a centralized 
roaming user management is possible. 

Brief description of the drawings 

30 

In the following, the present invention will be described 
in greater detail with reference to the accompanying 
drawings, in which 
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Fig. 1 shows a hierarchical AAA deployment in a domain- 
based manner according to the prior art; 

Fig. 2 is an illustration showing the internal protocol 
5 structure of nodes of a domain according to Fig. 1. 

Fig. 3 shows a destination determination procedure in 
response to an AAA service request according to the prior 
art . 

10 

Fig. 4 shows a node deployment with a local redirector 
within a domain of a domain-based network according to 
the present invention. 

15 Figs. 5A to 5D show examples of routing tables of a 

redirector and an entry node, each according to the prior 
art and to the present invention. 

Fig. 6 shows a destination determination procedure in 
20 response to a service request according to the present 
invention. 

Fig. 7 shows a more detailed destination determination 
procedure according to Fig. 6 with contents of respective 
25 messages being exchanged during the procedure. 

Fig. 8 shows a block diagram of an internal structure of 
network nodes according to the present invention. 

30 Detailed description of an embodiment of the present 
invention 

It is to be noted that the present invention will be 
described with a specific focus on the usage of an AAA 
35 network and the Diameter base protocol specified by the 
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IETF AAA Working Group as the underlying AAA^ protocol . 
Nevertheless, the present invention is not limited to 
either of both but is also applicable to other types of 
domain-based networks (e.g. operation and management 
5 networks of mobile communication networks ) providing 
user-related services and protocols therefor, e.g. 
RADIUS, as long as these other protocols are similar to 
the Diameter protocol and support or are compatible to at 
least to the routing functionality offered by Diameter. 

10 

Furthermore, the underlying domain-based communication 
network is herein exemplary described to be the Internet. 
However, any other domain-based communication network is 
conceivable, such as a 3G mobile communication system. 

15 ,,; 
According to an embodiment of the present invention, Frg. 
4 shows a node deployment with a local redirector within 
a domain of a domain-based network according to the ? 
present invention. 

20 L- 
Basically, the illustration of Fig. 4 according to the h 
present invention corresponds to the illustration of Fig. 
1 according to the prior art. Namely, Fig. 4 only shows 
the domain Dom__A of service provider A. Consequently, 

25 entities with like reference signs than that of Fig. 1 

represent comparable entities and their description will 
be omitted. 

A so-called ^enhanced local AAA redirector" is newly 
30 introduced into the network topology within this domain. 
This redirector denoted with A2 will hereinafter be 
referred to as an intermediate node since it is located 
in between the entry node Al representing a first 
hierarchy layer and the service nodes A3a, A3b, A3c 
35 representing a second hierarchy layer. The intermediate 
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node A2 is connected to the entry node, to a database 
(not shown) and to all service nodes A3a, A3b, A3c. It is 
adapted to provide and/or provides a redirecting function 
within domain Dom_A. A detailed description of such a 
5 local redirecting function will follow with reference to 
Figs. 6 and 7. 

It is to be noted that domain Dom_A serves as an example 
and that everything in this regard may also apply to any 
other domain of the network. 

10 

The present invention utilizes a routing function of an 
underlying AAA protocol, e.g. the Diameter base protocol 
routing function, to achieve efficient processing of 
(AAA) service requests. Further, the present invention 

15 utilizes the function of redirecting which is adapted to 
be and/or is available for processing of service requests 
within each domain of the domain-based network, 
irrespective of a redirecting function in-between 
different domains as is provided by redirector R 

20 according to the prior art. 

In the present invention, the redirect procedure is 
adopted in such a way that unrecognized service requests, 
i.e. service requests in which the destination service 

25 node is not specified, are handled by the above-mentioned 
intermediate node A2 . The intermediate node A2 then 
obtains the appropriate destination service node for the 
service request by performing a database look-up in a 
user database to find out the destination service node 

30 for the user originating the service request. It then 
sends back the respective information to the node from 
which it received the service request, and the service 
request will be forwarded by this node on the basis of 
its destination information. The redirect actions 

35 according to the present invention are based on the 
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domain name and on the user name as known from the prior 
art. However, the redirect function according to the 
present invention is performed below the application 
layer of the protocol, e.g. the Diameter application 
5 layer. In the following, the such enhanced functionality 
will be explained in detail. 

Therefore, Figs. 5A to 5D show examples of routing tables 
of a redirector and an entry node, each according to the 
10 prior art and to the present invention. 

A conventional domain-independent redirector redirects 
messages according to its domain-based routing table as 
the one shown in Fig. 5A, for example. It can be seen 

15 that the source domain (or source realm) does not have' 

any influence on the routing procedure and can, hence*, be 
arbitrary (*) . A message with target domain (or target* 
realm) finland.com, for example, will be handled 
according to the respective action, i.e. redirect. Thus, 

20 this message will be redirected to the node specified 'as 
next hop, i.e. the entry node of the respective domain,' 
flnland.com, e.g. entry.finland.com. In case a domain has 
one or more further entry nodes than the one specified as 
next hop, these are specified as alternative redirect- 

25 hosts. If one entry node is not in operation or can not 
be reached due to a connection failure or the like, the 
message will be redirected to this alternative redirect- 
host, e.g. entryway.moon.com for domain moon . com. 

30 In the perspective of the redirector with the above 

referenced routing table, all target domains are foreign 
domains since the redirector is located outside of all 
domains as described above with regard to the prior art 
deployment (see Fig. 1) . 

35 
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The enhanced local redirector according to the present 
invention is part of the domain of a service provider, 
and thus there also exists a localdomain from its 
perspective. If the target domain is localdomain, i.e. 
5 the home domain of the user originating the service 

request is equal to the home domain of the redirector, 
the message can not be redirected in a conventional way 
due to a lack of an appropriate action in the 
conventional routing table of Fig. 5A. Therefore, when 
10 adopting the present invention, the routing table of Fig. 
5A is adapted in the way shown in Fig. 5B, i.e. an action 
„orient" is to be added for the case of target realm 
being localdomain. 

15 Then, the message is „oriented xx to a user database (not 
shown) of this domain, e.g. userDB. localdomain. com. 
This newly introduced „orient xx action initiates the look- 
up in the user database server and the querying of the 
destination service node for the user being specified by 

20 the current service request. 

A detailed description and explanation of the method of 
redirecting service requests will be given in the 
following by means of two examples. 

25 

[ First example ] 

In a first example, the following problem is dealt with. 
When a user is roaming in a foreign domain, a service 
30 request will be sent back to the user's home domain, if 
the user requires a user-related (AAA) service. As, for 
example, the Diameter base protocol for AAA networks 
suggests, the request will according to the prior art be 
handled locally by the entry node. The corresponding 
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routing table of such a conventional entry node is shown 
in Fig. 5C. 

Yet, such local processing could easily cause the node 
5 being loaded over burden, if there are a lot of requests 
coming in at a time* In this regard, it is to be noted 
that the service request has also to be analyzed before 
its processing with respect to redirecting. Additionally, 
the domain entry node in a domain that has more than one 

10 service node would be puzzled since the incoming service 
request does not explicitly specify the destination host 
(destination service node) . For being able to perform a 
redirect function, the node would have to modify the 
message after querying the database for the destination 

15 host. By doing so, the security measures adopted, e.g. . by 
the Diameter application, would be violated because the 
entry node sits in the forwarding path and is therefore 
not allowed to modify incoming service requests. Thus, 
this solution is not feasible. * 

2 0 

In this example, according to the invention, when the ?: 
entry node receives a service request from a outside of: 
its domain, it will not process it locally as known from 
the prior art. Rather, the service request lacking 

25 destination information will be transmitted to a local 
redirector of the localdomain for further instructions 
and/or information. Therefore, the domain-based routing 
table for the entry node is modified according Fig. 5D. 
Therein, a message for the localdomain will be relayed to 

30 a local redirector, e.g. redirector.localdomain.com, 

which performs the redirecting function according to the 
routing table of Fig. 5B. 

Fig. 6 shows a destination determination procedure in 
35 response to a service request coming from outside a local 
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* 

domain according to the first example of the present 
invention. 

Basically, Fig. 6 corresponds to Fig. 3 in that these 
5 figures are based on the same scenario. However, the two 
nodes of Fig. 3 constituting the lower branch on the left 
side, i.e. service node A3c and access node A3cl, are 
omitted, and an intermediate node A2 , i.e. an enhanced 
local AAA redirector, is newly introduced. It can be seen 
10 that the procedural steps (1) and (4) are comparable, but 
that procedural steps (2) and (3) clearly differ when 
comparing Fig. 3 according to the prior art and Fig. 6 
according to the invention. 

15 After receiving (1) of the service request in the peer 
FSM layer of the entry node Al, the service request is 
analyzed in terms of destination information contained in 
the service request. Upon this analyzing, it is 
determined, whether the destination information enables a 

20 direct forwarding of the service request to its 

destination. If said determining yields that said direct 
forwarding is enabled, the service request will be 
forwarded by the entry node directly to its destination, 
e.g. service node aaa.bGijing.china.com. In this case, 

25 e.g. when the destination information contained in the 

service request enable a direct forwarding, a redirecting 
of the service request under discussion is not performed. 

However, if said determining yields that said direct 
30 forwarding is not enabled, the service request will be 

redirected, and such redirecting is performed as follows. 

In the redirecting process, the service request is not 
transferred to the application layer of the entry node Al 
35 to be processed locally, but it is processed according to 
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the routing table of the entry node according to the 
present invention (see Fig. 5D) . Accordingly, the service 
request is relayed to the local redirector, i.e. 
transmitted (2) to the peer FSM layer of the intermediate 
5 node A2 . From thereon, a database look-up is performed 
according to the routing table of the local redirector 
according to the present invention (see Fig. 5B) , i.e. 
the service request is oriented to the user database. The 
look-up is based on the received service request and is 

10 performed for obtaining destination information requires 
to enable a forwarding of this service request to its 
destination. The result of the look-up, i.e. the 
destination information for the respective service 
request, is received at the peer FSM layer of the 

15 intermediate node A2, and sent (3) from the intermediate 
node A2 to the peer FSM layer of the entry node Al . From 
there, the modified service request is, based on the 'aent 
destination information, forwarded (4) to its 
destination, namely service node aaa.beijing.chlna.com. 

V 

20 The respective access node, namely v: 

y 

beijing2.beijing.china.com, is again not involved in .the 
processing of this service request. f. 

In prior art, the entry node is often implemented by 
25 using a proxy node. According to the invention, the upper 
two layers of the protocol stack of the entry node are 
not involved any more for the processing of incoming 
messages as described above. This alleviates the 
requirements on the node. Thus, it is also possible to 
30 replace the proxy by a simple relay node and the policy 
processing can be handled in the local service node 
against the user's locale profile. This saves costs and 
implementation effort and can improve the robustness of 
the system. 



35 
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In Fig. 7 , the destination determination procedure 
according to Fig. 6 is shown with greater detail in that 
the contents of respective messages being exchanged 
during the procedure are shown. The left part of Fig. 7 
5 differs from Fig. 6 only in that the two upper protocol 
layers of the entry node Al, i.e. the session FSM layer 
and the application layer, are not shown since these are 
not involved any more in connection with the present 
invention, and that the access node A3a2 is not shown. In 
10 the following, the procedure will be described again with 
regard to the messages being exchanged and their 
contents . 

In this scenario, china.com is the localdoma in under 

15 inspection, . and the user liuqing being associated to the 
service node aaa.beijing.china.com originated a service 
request from a foreign domain to his/her home domain. 
This request (REQ) message (Message 1) being input to the 
entry node Al of domain china . com contains the 

20 information that china.com is the destination domain and 
that liuqing is the concerned user name. The message is 
transmitted to the intermediate node A2 for further 
instruction because it does not specify the destination 
service. node (destination host) for the user liuqing. 

25 This is also the case here since the present invention 

does not modify the underlying protocol. With the updated 
routing table of the entry node (see Fig. 5D) , 
redirector.china.com is introduced into the service 
request (Message 2) as (temporary) destination host. The 

30 other information fields remain unchanged. 

The intermediate node named redirector.china.com detects 
its local domain china.com as destination domain (see 
Fig. 5B) and, therefore, queries a database for the home 
35 service node (host) for the user liuqing by a look-up 
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into the user database DB_A of the domain china . com. The 
intermediate node then replies the result of the look-up 
to the entry node Al by sending an error (ERR) message 
(Message 3) . This error message contains not only the 
5 destination domain and user name like above, but 

additionally contains an information in the redirect host 
field, namely aaa.beijing.chxna.com, i.e. the service 
node (for the user concerned) to which the service 
request is to be redirected. The service request is then 
10 updated with this new information, i.e. destination host 
is changed from its temporary assignment 

redirector.china.com into the actual destination service 
node of the user liuqing which is aaa.beijing.china.com. 
At this point, the entry node forwards the accordingly 
15 adapted service request (Message 4) to the destination 
service node (destination host) of the user under 
discussion, and the processing of the service request is 
completed as known from the art. 

20 The exemplary messages of Fig. 7 correspond to message 
formats (e.g., REQ, ERR) known from the Diameter base;- 
protocol. The respective information is shown to be ^ 
contained in predetermined information fields (e.g. 
destination-realm, user-name) within such messages, so- 

25 called attribute-value-pairs (AVP) . However, other 
message formats and information fields being 
predetermined by other protocols can also be used when 
adapting the invention. Thus, the invention is not 
limited to the use of the Diameter base protocol. 

30 

[ Second example ] 



35 



In a large domain, more than one service node prevails in 
this domain, and thus, different service nodes share the 
same domain name. In this example, a user being 
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associated to a first service node, e.g. 

aaa.beijing.china.com A3a currently accesses the network 
via an access node, e.g. hongkongl.hongkong.china.com 
A3cl which is connected to a second service node, e.g. 
5 aaa.hongkong.china.com A3c, whereby this second service 
node has the same domain name as the first one, namely 
china . com. Such a scenario is also known as intra-domain 
or sub-domain roaming. A service node receiving a service 
request from a user being associated with another service 

10 node of the same domain would then be puzzled since the 
service request of such a roaming user does not specify 
the destination service node (home server) of the user. 
And users are not likely to specify their home service 
node when they roam under another service node within 

15 their home domain. Such a service request would only 

contain the home domain and the user name. However, this 
would according to the prior art result in a processing 
of the service request in the entry node of the domain. 

20 However, utilization of the entry node, which is deployed 
at the boundary of the administrative domain, is not 
preferable to handle roaming within sub-domains. 
Especially with a Diameter implementation, the routing 
decisions should be made within the Diameter base 

25 protocol and not by defining respective Diameter 

applications. It would therefore introduce too much 
implementation efforts if the entry node is used to 
handle many Diameter applications, which would be the 
case when handling of sub-domain roaming would take place 

30 in the entry node. 

In this example, one of a plurality of service nodes of a 

respective domain, with which the user originating the 

service request is not associated receives the service 

i 

35 request from within this domain. According to the present 



10 
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invention, when a service node receives such an 
^unrecognized^ service request for the local domain, -it 
transmits the request to an intermediate node according 
to the invention for providing a redirecting function. 
The redirector then detects localdomain to be the target 
domain and, thus, relays the request with the domain name 
and the user name to the user DB server as is already 
described in the first example. The following procedure 
is the same as described above. 



From this second example, it can be seen that a service 
request can be input to different nodes of a network, 
i.e. an entry node for service requests coming from 
outside the domain and a service node for service 

15 requests coming from within the domain, each being an > - 
example representing a ^service request input node" t 
within the framework of the present definitions of \> 
terminology adopted in the present specification. The * 
basic internal structures of such a service request input 

20 node and an intermediate node according to the present 4* 
invention are shown in the block diagram of Fig. 8. 

In Fig. 8, a service request input node is exemplary 
shown as an entry node Al. Thereby, solid arrow lines 
25 represent the process of messages (i.e., service request 
and database inquiry message), whereas the dashed arrow 
lines represent control connections. 

A service request input node, irrespective of whether it 
30 is an entry node or a service node, receives and 

processes an incoming service request and controls the 
local redirecting function. Thus, is comprises analyzing 
means All, determining means A12, redirecting control 
means A13, transmitting means A14, and forwarding means 
35 A15. Thereby the analyzing means All analyze an incoming 
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service request in terms of destination information 
contained therein, the determining means A12 determine, 
whether the destination information enables a direct 
forwarding of the service request to its destination, the 
5 redirecting control means A13 control a redirecting of a 
service request, if the determining means yield that said 
direct forwarding is not enabled, and the transmitting 
means A14 then transmit the received service request to 
an intermediate node A2 . The forwarding means A15 either 

10 forward the service request directly to its destination, 
if the determining means yield that such direct 
forwarding is enabled, or forward based on the 
destination information sent by an intermediate node, the 
service request to its destination as part of a 

15 redirecting procedure* 

Furthermore, an intermediate node according to the 
invention comprises receiving means A21 which receive a 
service request from a service request input node, look- 

20 up means A22 which perform, based on the service request, 
a look-up in a database DB_A for obtaining destination 
information required to enable a forwarding of the 
service request to its destination, and sending means A23 
which send the destination information to the service 

25 request input node from which the service request was 
received. 

According to the present invention a method, a system and 
corresponding network entities for processing service 

30 requests in a domain of a network which network consists 
of a plurality of domains are provided, which method 
comprising the steps of: analyzing an incoming service 
request in a service request input node in terms of 
destination information contained in said service 

35 request; determining in said service request input node, 
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whether the destination information enables a direct 
forwarding of said service request to its destinations- 
redirecting said service request by said service request 
input node, if said determining yields that said direct 
5 forwarding is not enabled; wherein said redirecting 
comprises the steps of: transmitting said received 
service request by said service request input node to an 
intermediate node; based on said received service 
request, performing a look-up in a database by said • 

10 intermediate node for obtaining destination information 
required to enable a forwarding of said service request 
to its destination; sending said destination information 
from said intermediate node to said service request input 
node; and based on said sent destination information, 

15 forwarding said service request from said service request 
input node to its destination. , 

While the invention has been described with reference to 
a preferred embodiment, the description is illustrative; - 
20 of the invention and is not to be construed as limiting'/^, 
the invention. Various modifications and applications may 
occur to those skilled in the art without departing from 
the true spirit and scope of the invention as defined by v 
the appended claims . 



Claims 
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1. A method for processing service requests in a (}Qi^i*>i v *~ ' 
(Dom_A) of a network which network consists of a 
5 plurality of domains (Dom_A, Dom_B, Dom_C) , wherein 

said service requests originate from a user terminal 
associated with a service node of said domain ( Dom_A ) , 
and wherein a domain (Dom_A, Dom_B, Dom_C) at least 
comprises a service request input node (Al, A3a, A3b, 

10 A3c) , an intermediate node (A2) , a database (DB_A) , an 

entry node (Al) , and a plurality of service nodes (A3a, 
A3b, A3c) , and wherein said service request input node 
is connected to said intermediate node (A2), to said 
entry node (Al) and to said service nodes (A3a, A3b, 

15 A3c) , said intermediate node (A2) is further connected 

to said database (DB__A) and to said service nodes (A3a, 
A3b, A3c) , and said service nodes (A3a, A3b, A3c) aref 
further connected to each other; said method comprising 
the steps of: 

20 analyzing an incoming service request in said f. 

service request input node in terms of destination 

information contained in said service request; \ 
determining in said service request input node, 

whether the destination information enables a direct 
25 forwarding of said service request to its destinations- 

redirecting said service request by said service 

request input node, if said determining yields that 

said direct forwarding is not enabled; wherein said 

redirecting comprises the steps of: 
30 transmitting said received service request by said 

service request input node to said intermediate node 

(A2); 

based on said received service request, performing 
a look-up in said database (DB_A) by said intermediate 
35 node (A2) for obtaining destination information 
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required to enable a forwarding of said service request 
to its destination; 

sending said destination information from said 
intermediate node (A2) to said service request inpat 
5 node; and 

based on said sent destination information, 
forwarding said service request from said service 
request input node to its destination. 

10 2. A method according to claim 1, further comprising a 

step of direct forwarding said service request by said 
service request input node to its destination, if said 
determining yields that said direct forwarding is 
enabled . 

15 

3. A method according to claim 1 or 2, wherein said 
service request input node is an entry node (Al) of 
said domain (Dom_A) , and wherein said entry node (Al) 
receives said service request from outside of said 

20 domain (Dom_A) . 

4. A method according to claim 1 or 2, wherein said 
service request input node is one of a plurality of 
service nodes (A3a, A3b, A3c) of said domain (Dom__A), 

25 with which the user terminal originating said service 

request is not associated, wherein said one of the 
plurality of service nodes (A3a, A3b, A3c) receives 
said service request from within said domain (Dom_A). 

30 5. A method according to claim 4, wherein said service 

request input node determines that the received service 
request from within said domain (Dom__A) is destined for 
a user terminal being associated with a service node 
(A3a f A3b, A3c) of said domain (Dom_A), and in response 

35 thereto redirects said service request. 
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6. A method according to claim 4, wherein said service 
request input node determines that the received service 
request from within said domain (Dom_A) is destined for 

5 a user terminal not being associated with a service 

node (A3a, A3b, A3c) of said domain (Dom_A) , and 
forwards said service request to said entry node (Al) 
of said domain (Dom_A) for relaying said service 
request to another domain (Dom_B, Dom_C) . 

10 

7. A method according to any preceding claim, wherein 
said service requests are AAA service requests 
associated with authentication, authorization, and 
accounting functions . 

15 : 

8. A method according to claim 7, wherein service 
requests are processed based on the Diameter base ' v ' 
protocol . > 

20 9. A method according to any of claims 3 to 8, wherein <? 

said entry node of said domain (Dom__A) is a proxy node. 

» }. 

10. A method according to any of claims 3 to 8, wherein 
25 said entry node of said domain (Dom_A) is a relay node. 

11. A method according to any preceding claim, wherein 
the network consisting of a plurality of domains 

30 (Dom__A, Dom_B, Dom_C) is the Internet and the domains 

( Dom__A j Dom__B, Dom_C) are established by respective 
service providers (A, B, C) . 

12. A method according to any of claims 1 to 10, wherein 
35 the network consisting of a plurality of domains 
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(Dom__A, Dom__B, Dom_C) is a 3G mobile communication 
network. 



13. A system for processing service requests in a domain 
5 (Dom_A) of a network which network consists of a 

plurality of domains (Dorri_A, Dom_B, Dom_C) , wherein 
said service requests originate from a user terminal 
associated with a service node of said domain (Dom__A) , 
and wherein a domain (Dom_A, Dom_B, Dom__C) at least 

10 comprises a service request input node (Al, A3a, A3b, 

A3c) , an intermediate node (A2) , a database (DB_A) , an 
entry node (Al), and a plurality of service nodes (A3a, 
A3b, A3c) , and wherein said service request input node 
is connected to said intermediate node (A2) , to said 

15 entry node (Al) and to said service nodes (A3a, A3b, 

A3c) , said intermediate node (A2) is further connected 
to said database (DB_A) and to said service nodes (A3a, 
A3b, A3c) , and said service nodes (A3a, A3b, A3c) are 
further connected to each other; said system 

20 comprising: 

analyzing means (All) in said service request 
input node which analyze an incoming service request in 
terms of destination information contained in said 
service request; 

25 determining means (A12) in said service request 

input node which determine, whether the destination 
information enables a direct forwarding of said service 
request to its destination; 

redirecting control means (A13) in said service 

30 request input node which control a redirecting of said 

service request, if said determining means yields that 
said direct forwarding is not enabled; wherein said 
redirecting is performed by: 

transmitting means (A14) in said service request 

35 input node which transmit said received service request 
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from said service request input node to said 
intermediate node (A2); 

look-up means (A22) in said intermediate node (A2) 
which perform, based on said service request received 
5 by receiving means (A21) , a look-up in said database 

(DB_A) for obtaining destination information required 
to enable a forwarding of said service request to its 
destination; 

sending means (A23) in said intermediate node (A2) 
10 which send said destination information from said 

intermediate node (A2) to said service request input 
node; and 

forwarding means (A15) in said service request 
input node which forward said service request, based on 
15 said sent destination information, from said service 

request input node to its destination. * 

•t . 

14. A system according to claim 13, further comprising - 
forwarding means in said service request input node 

20 which forward said service request to its destination, 'i 

if said determining means yields that said direct t 
forwarding is enabled. ^ 

15. A system according to claim 13 or 14, wherein said 
2 5 service request input node is an entry node (Al) of 

said domain (Dom_A) , and wherein said entry node (Al) 
receives said service request from outside of said 
domain ( Dom__A) . 

30 16. A system according to claim 13 or 14, wherein said 
service request input node is one of a plurality of 
service nodes (A3a, A3b, A3c) of said domain ( Dom__A) , 
with which the user terminal originating said service 
request is not associated, wherein said one of the 
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plurality of service nodes (A3a, A3b, A3c) receives 
said service request from within said domain (Dom_A) . 

17. A system according to claim 16, wherein said service 
5 request input node comprises determining means which 

determine, whether the received service request from 
within said domain (Dom_A) is destined for a user 
terminal being associated with a service node (A3a, 
A3b, A3c) of said domain ( Dom_A ) , and redirecting means 
10 which redirect said service request, if said service 

request is destined for a user terminal being 
associated with a service node (A3a, A3b, A3c) of said 
domain (Dom_A) . 

15 18. A system according to claim 16, wherein said service 
request input node comprises determining means which 
determine, whether the received service request from 
within said domain (Dom_A) is destined for a user 
terminal not being associated with a service node (A3a, 

20 A3b, A3c) of said domain (Dom_A) , and forwarding means 

which forward said service request to said entry node 
(Al) of said domain (Dom_A) for relaying said service 
request to another domain (Dom_B, Dom_C) , if said 
service request is destined for a user terminal not 

25 being associated with a service node (A3a, A3b, A3c) of 

said domain (Dom_A) . 

19. A system according to any of claims 13 to 18, wherein 
said service requests are AAA service requests 
30 associated with authentication, authorization, and 

accounting functions. 



35 



20. A system according to claim 19, wherein service 
requests are processed based on the Diameter base 
protocol . 



21. A system according to any of claims 15 to 20, wherein* 
said entry node of said domain (Dom__A) is a proxy node. 



22. A system according to any of claims 15 to 20, wherein 
said entry node of said domain (Dom_A) is a relay node. 



23. A system according to any of claims 13 to 22, wherein 
the network consisting of a plurality of domains 
(Dom_A, Dom_B, Dom_C) is the Internet and the domains 
(Dom__A, Dom_B, Dom_C) are established by respective 
service providers (A, B, C) . 

24. A system according to any of claims 13 to 22, wherein 
the network consisting of a plurality of domains 'i •* 
(Dom_A, Dom_B, Dom_C) is a 3G mobile communication 
network. ' - 

25. An intermediate node (A2) which redirects service -* 
requests within a domain (Dom_A) of a network which <?i 
network consists of a plurality of domains ( Dom_A, 
Dom_B, Dom_C) , wherein said intermediate node (A2) is 
connected to an entry node (Al), to a database (DB_A), 
and to a plurality of service nodes (A3a, A3b, A3c) of 
said domain; said intermediate node comprising: 

a) receiving means (A21) which receive said 
service request from a service request input node (Al, 
A3a, A3b, A3c) ; 

b) look-up means (A22) which perform, based on 
said received service request, a look-up in said 
database ( DB_A) for obtaining destination information 
required to enable a forwarding of said service request 
to its destination; 
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c) sending means (A23) which send said destination 
information from said intermediate node (A2) to said 
service request input node. 

5 26. An intermediate node according to claim 25, wherein 
said service requests are AAA service requests 
associated with authentication, authorization, and 
accounting functions . 



10 27. A service node (A3a, A3b, A3c) of a domain ( Dom__A ) of 
a network which network consists of a plurality of 
domains ( Dom_A , Dom__B, Dom_C) , wherein said service 
node provides services for a user terminal associated 
with said service node, which services are requested by 

15 service requests originating from said user terminal, 

wherein said service node is connected to an entry node 
(Al) of said domain (Dom_A), to an intermediate node 
(A2) of said domain ( Dom_A) which redirects service 
requests within said domain (Dom_A) , and to all other 

20 service nodes of said domain (A3a, A3b, A3c) . 



28. A service node according to claim 27, wherein said 
service requests are AAA service requests associated 
25 with authentication, authorization, and accounting 

purposes functions . 



29. A service request input node within a domain (Dom__A) 
of a network which network consists of a plurality of 

30 domains (Dom_A, Dom_B, Dom_C) , wherein said service 

request input node processes service requests 
originated from user terminals of said network, and 
wherein said service request input node is connected to 
an intermediate node (A2) of said domain (Dom_A) which 

35 redirects service requests within a domain ( Dom__A ) , and 
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to a plurality of service nodes of said domain (Dom__A); 
said service request input node comprising: 

redirecting control means (A13) which control a 
redirecting of a received incoming service request; 
5 transmitting means (A14) which transmit said 

received service request to said intermediate node (A2) 
for obtaining destination information required to 
enable a forwarding of said service request to its 
destination; 

10 forwarding means (A15) which forward said service 

request, based on said received destination 
information, from said service request input node to 
its destination. 

15 30. A service request input node according to claim 29, ; 

wherein said service request input node is an entry * 
node (Al) of said domain (Dom__A) , and receives said 
service requests from outside of said domain (Dom_A) . * 

20 31. A service request input node according to claim 29,'. 

t. 

wherein said service request input node is a service 

V. 

node (A3a, A3b, A3c) of said domain (Dom_A), and 
receives said service requests from within said domain 
( Dom_A ) . 

25 

32. A service request input node according to claim 31, 
further comprising determining means which determine, 
whether the received service request from within said 
domain (Dom_A) is destined for a user terminal being 
30 associated with a service node (A3a, A3b, A3c) of said 

domain (Dom_A) , and redirects said service request, if 
said service request is destined for a user terminal 
being associated with a service node (A3a, A3b, A3c) of 
said domain (Dom_A) . 

35 
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33. A service request input node according to claim 31, 
further comprising determining means which determine, 
whether the received service request from within said 
domain (Dom_A) is destined for a user terminal not 

5 being associated with a service node (A3a, A3b, A3c) of 

said domain (Dom__A) , and forwarding means which forward 
said service request to an entry node (Al) of said 
domain (Dom_A) for relaying said service request to 
another domain ( Dom_B , Dom_C) , if said service request 
10 is destined for a user terminal not being associated 

with a service node (A3a, A3b, A3c) of said domain 
( Dom_A ) . 

34 . A service request input node according to any of 

15 claims 29 to 33, wherein said service requests are AAA 

service requests associated with authentication, 
authorization, and accounting functions. 



Abstract 
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cpo - Munich 
80 

27.0kl.2D» 



A method, a system and corresponding network entities for 
processing service requests in a domain of a network 
5 which network consists of a plurality of domains, 

comprising the steps of: analyzing an incoming service 
request in a service request input node in terms of 
destination information contained in said service 
request; determining in said service request input node, 

10 whether the destination information enables a direct 

forwarding of said service request to its destinations- 
redirecting said service request by said service request 
input node, if said determining yields that said direct 
forwarding is not enabled; wherein said redirecting 

15 comprises the steps of: transmitting said received 

service request by said service request input node to an 
intermediate node; based on said received service 
request, performing a look-up in a database by said 
intermediate node for obtaining destination information 

20 required to enable a forwarding of said service request 

to its destination; sending said destination information- 
from said intermediate node to said service request input 
node; and based on said sent destination information, 
forwarding said service request from said service request 

25 input node to its destination. 
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